前言
昨天我們理解了 API 的概念。今天要動手做一件實際的事:寫一段簡單的 Python 腳本,示範讀取一份 CSV 資料、組裝成 prompt、呼叫 API、拿到回應這一整個流程的最小可行版本。
今天的目標不是打造一套完整的正式系統,而是先讓整個串接邏輯「跑得通」,細節與例外處理留到後續逐步補強。

一、這段腳本要做的四件事
對照昨天畫出的自動化流程,今天先聚焦在最核心的四個步驟:

① 讀取 CSV 資料
② 把資料套進範本(Day 18 設計的佔位符邏輯)
③ 呼叫 API,把組好的 prompt 送出去
④ 接收並儲存回傳結果
二、步驟一:讀取 CSV 資料
Python 有內建的 csv 模組,可以直接讀取表格資料,轉換成程式容易處理的格式:

python
import csv

def read_events(filepath):
events = []
with open(filepath, encoding='utf-8') as f:
reader = csv.DictReader(f)
for row in reader:
events.append(row)
return events
這段程式,對應到 Day 15 談過的資料預處理概念——DictReader 會自動把每一列資料,轉換成一個「欄位名稱對應到值」的結構,方便後續程式依照欄位名稱抓取需要的資訊。
三、步驟二:把資料套進範本
這一步,就是把 Day 18 設計的佔位符邏輯,實際用程式實現:

python
def build_prompt(template, events):
total = len(events)
closed = sum(1 for e in events if e['狀態'] == '已結案')

filled = template.replace('{事件總數}', str(total))
filled = filled.replace('{已結案數}', str(closed))
filled = filled.replace('{處理中數}', str(total - closed))
return filled

這段程式做的事情很單純:把範本裡的佔位符,依序替換成從資料算出來的實際數字。你會發現,這正是 Day 18 談過的「佔位符解決填空題,規則解決問答題」的實際落地——填空題的部分,現在完全交給程式自動處理了。
四、步驟三:呼叫 API
這一步的具體寫法,會依照你們公司 AI 工具實際提供的 API 規格而不同(通常需要參考該工具的技術文件),但概念上的結構大致會長這樣:

python
import requests

def call_ai_api(prompt, api_key, api_url):
headers = {
'Authorization': f'Bearer {api_key}',
'Content-Type': 'application/json'
}
payload = {
'prompt': prompt
# 實際欄位名稱依公司 API 規格調整
}
response = requests.post(api_url, headers=headers, json=payload)
response.raise_for_status()
return response.json()
這裡有兩個重點需要特別留意:

• api_key 是機敏資訊,絕對不能直接寫死在程式碼裡——這一點,我們會在 Day 29 更完整地討論怎麼妥善保存與管理
• response.raise_for_status() 這行,是在確保如果 API 呼叫失敗(例如金鑰過期、網路問題),程式會立刻明確地報錯,而不是安靜地假裝成功、卻拿到一個空的或錯誤的結果
  五、步驟四:儲存結果
  拿到回應後,把生成的 .md 內容存成檔案:

python
def save_report(content, output_path):
with open(output_path, 'w', encoding='utf-8') as f:
f.write(content)
六、把四個步驟串起來

python
events = read_events('this_week_events.csv')
prompt = build_prompt(system_prompt_template, events)
result = call_ai_api(prompt, api_key='你的金鑰', api_url='API網址')
save_report(result['content'], 'weekly_report.md')
到這裡,一個最基本的自動化流程,理論上就能跑通了——輸入是一份 CSV,輸出是一份 .md 報告,中間完全不需要人工介入操作對話介面。
七、今天寫的只是「最小可行版本」,還缺什麼?
這段腳本刻意寫得很精簡,是為了先驗證整個流程的邏輯通不通。它目前還沒處理的部分,包括:

• 如果 API 呼叫失敗(網路問題、金鑰錯誤)該怎麼辦?
• 如果 CSV 裡有 Day 12 談過的資料異常(缺漏、格式錯誤),程式該怎麼因應?
• 產出結果要怎麼自動推送出去,而不是只是存成本機檔案?
  前兩項屬於程式的錯誤處理範疇,建議你在確認基本流程能跑通之後,再逐步補強;第三項,就是明天要談的內容。
  八、今天的行動練習
  如果你已經確認公司 AI 工具有提供 API,試著用一份少量的測試資料(不是機敏正式資料),實際跑一次今天的四個步驟,確認整個流程真的能順利跑通。如果暫時還沒有 API 存取權限,可以先把前兩個步驟(讀取資料、套用範本)寫出來並測試,第三步等權限到位後再補上。

小結
今天我們把前 25 天累積的所有概念,第一次真正落地成可執行的程式碼。這段腳本雖然簡單,卻完整走過了「資料 → 範本 → API → 結果」這條自動化的核心路徑,也讓 Day 18 的佔位符設計,從紙上的規則,變成程式裡實際運作的邏輯。
明天,我們要把「產出報告」這件事,再往前推一步——串接 Slack、Teams 或 Email,讓報告自動送到該送的地方,不需要你手動轉發。